Changes

• Adds an Open Source Policy to the project.
• Makes Elixir ready for OpenChain certification

TODOs

• Possibly split contribution section of README into CONTRIBUTING.md - in Split README from CONTRIBUTING #14297
• Setup Mailing List

OpenChain Checklist

Section 1: Program foundation

We have a documented policy governing the open source license compliance of supplied software.

Yes, will be published at https://github.com/elixir-lang/elixir/blob/main/OPEN_SOURCE_POLICY.md

We have a documented procedure to communicate the existence of the open source policy to program participants.

• Published Policy
• Referenced in README
• Once certified, we'll also add a badge to the README

We have identified the roles and responsibilities that affect the performance and effectiveness of the program.

See Policy §7

We have identified and documented the competencies required for each role.

See Policy §7

We have documented the assessed competence for each program participant.

See Policy §7

We have documented the awareness of our Program participants on the following topics:

• The open source policy and where to find it;
• Relevant open source objectives;
• Contributions expected to ensure the effectiveness of the Program;
• The implications of failing to follow the Program requirements.

See Policy §4, §6, §8

This PR should be approved by all of the Elixir Core Team as to make sure that the whole team is familiar with the policy.

New Core Team Members will have to familiarize themselves with the Open Source Policy.

We have a process for determining the scope of our Program.

See Policy §2

We have a written statement clearly defining the scope and limits of the Program.

See Policy §2

Section 2: Relevant tasks defined and supported

We assigned individual(s) responsibility for receiving external open source compliance inquiries.

See Policy §7.3

The external open source compliance contact is publicly identified (e.g. via an email address or the Linux Foundation Open Compliance Directory).

See Policy §9

We have a documented procedure for receiving and responding to open source compliance inquiries.

See Policy §9

We have documented the persons, group or function supporting the Program role(s) identified.

See Policy §7

We have ensured identified Program roles been properly staffed and adequately funded.

Checked, results are internal.

Legal expertise to address internal and external open source compliance has been identified.

See Policy §7.3, Complex matters: escalation to lawyer

We have a documented procedure assigning internal responsibilities for open source compliance.

See Policy §7.1

We have a documented procedure for handling review and remediation of non-compliant cases.

See Policy §4

Section 3: Open source content review and approval

We have a documented procedure for identifying, tracking and archiving information about the open source components in a Supplied Software release.

• CI produces Source SBoM
• SBoM’s are attached to GitHub releases

We have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed.

• CI evaluates rules
• Write results in form of SBoM to release

We have a documented procedure that covers these common open source license use cases for open source components in the Supplied Software:

• Distribution in binary form - Binary attested with Source SBoM
• Distribution in source form - See in GH releases
• Integration with other open source that may trigger additional obligations - Will be relevant once the scope covers the other Elixir projects.
• Containing modified open source - See Policy §4
• Containing open source or other software under incompatible licenses for interaction with other components in the Supplied Software - No allowed to be merged as per Policy
• Containing open source with attribution requirements - NOTICE can be generated using ORT once the requirement arises.

Section 4: Compliance artifact creation and delivery

We have a documented procedure describing the process for ensuring the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses.

• CI generates Source SBoM, in releases

We have a documented procedure for archiving copies of Compliance Artifacts for the Supplied Software.

CI places SBoM in releases

We archive the Compliance Artifacts at least as long as the Supplied Software is offered and as required by the Identified Licenses.

As long as project stays on GitHub. In case of migration somewhere else: Make sure to keep artefacts.

Compliance is only attested going forward from certification. Older versions may not comply.

Section 5: Understanding open source community engagements

We have a policy for contribution to open source projects on behalf of the organization.

See Policy §10

We have a documented procedure governing open source contributions.

See Policy §10

We have a documented procedure for making all Software Staff aware of the open source contribution policy.

Same as “Section 1: Program foundation”.

Section 6: Adherence to the specification requirements

We have documentation confirming that your Program meets all the requirements of this specification.

This PR

We have documentation confirming that your Program conformance was reviewed within the last 18 months.

See Policy §11